1. Field of the Invention
The present invention relates to computer communication, and deals more particularly with a technique, system, and computer program for maintaining session-related state information in a scalable, clustered network environment. This is preferably done in a manner that avoids the need to use persistent storage such as a database to store session information, thereby removing the performance penalty associated with database accesses. Further, a mechanism is provided whereby the integrity of the session data is protected from inadvertent overwriting. The technique is provided using industry-wide, standard APIs, allowing for increased portability, scalability, and acceptance of this solution.
2. Description of the Related Art
The Internet is a vast collection of computing resources, interconnected as a network, from sites around the world. It is used every day by millions of people. The World Wide Web (referred to herein as the "Web") is that portion of the Internet which uses the HyperText Transfer Protocol ("HTTP") as a protocol for exchanging messages. (Alternatively, the "HTTPS" protocol can be used, where this protocol is a security-enhanced version of HTTP.)
A user of the Internet typically accesses and uses the Internet by establishing a network connection through the services of an Internet Service Provider (ISP). An ISP provides computer users the ability to dial a telephone number using their computer modem (or other connection facility, such as satellite transmission), thereby establishing a connection to a remote computer owned or managed by the ISP. This remote computer then makes services available to the user's computer. Typical services include: providing a search facility to search throughout the interconnected computers of the Internet for items of interest to the user; a browse capability, for displaying information located with the search facility; and an electronic mail facility, with which the user can send and receive mail messages from other computer users.
The user working in a Web environment will have software running on his computer to allow him to create and send requests for information, and to see the results. These functions are typically combined in what is referred to as a "Web browser", or "browser". After the user has created his request using the browser, the request message is sent out into the Internet for processing. The target of the request message is one of the interconnected computers in the Internet network. That computer will receive the message, attempt to find the data satisfying the user's request, format that data for display with the user's browser, and return the formatted response to the browser software running on the user's computer.
This is an example of a client-server model of computing, where the machine at which the user requests information is referred to as the client, and the computer that locates the information and returns it to the client is the server. In the Web environment, the server is referred to as a "Web server".
The HTTP communications protocol uses a request/response paradigm, where the electronic messages sent between communicating computers can be categorized as either requests for information, or responses to those requests, as illustrated above. HTTP does not provide for maintaining any type of state information about the communications, instead treating each request/response pair as a separate and unrelated transaction. This approach works well for many Web transactions. For example, a user may request to see a specific document displayed on his browser. When it has been sent by the server and displayed to the user, there may be no further processing that relates to that request, and therefore nothing more to be done. However, there are many instances where this absence of state information is a serious shortcoming of the protocol. When there is no state information, then a server receiving requests from a client may have no way of knowing that it has received prior requests from this same client, and no way of making any type of logical connection between the multiple requests.
Some example scenarios where state information is an absolute necessity include on-line shopping, searching with successive refinement of search terms, and gathering user profile information. In on-line shopping, a user typically accesses a seller's on-line catalog, which will be displayed to him as some number of Web pages (where a "Web page" is the information displayable in response to a user's request). Typically, the user can display a separate page of information related to each product, to read about the details of that product. Each time the user requests to see a page, a separate HTTP request is typically sent to the Web server where the seller's product catalog is stored. This request indicates that data for a specific product should be gathered and sent to the client machine for display. When the user wishes to order a product, he indicates his selection by clicking on an "Order" button of some type, using a mouse, for example. This causes another request message to be sent to the server, where the request indicates that this is an order for the particular item. Without the ability to maintain state information, each of these requests would be treated as unrelated to the others. There would be no efficient way to collect orders for more than one item into one large order. Further, there would be no efficient way to allow the user to enter his name, address, credit card number, etc. only one time, and have that information apply to all the ordered items.
Searching for information, and then applying refinements to the search criteria, would suffer from the same inconveniences in the absence of state information. Obviously, users would not long tolerate shopping or searching in this way, so various methods of adding state information to HTTP's state-less environment have evolved. A typical approach to the searching scenario is to embed the search criteria into the URL (Uniform Resource Locator) of both the HTTP request and the response. Thus, when the user is viewing the result of his search criteria, those criteria are still available and can be further refined in a subsequent search message created from the text of this search. This carrying-along of the state-related information is not a viable approach in more detailed and complex examples such as on-line shopping, however. To deal with keeping larger amounts of data between related messages, the concept of a "session" has been introduced.
Sessions have been used for many years in other types of environments that preceded HTTP and the Web, and which were state-oriented. For example, the Systems Network Architecture ("SNA") from the International Business Machines Corporation ("IBM") is a state-oriented architecture and protocol. The Open Systems Interconnection ("OSI") architecture and protocols are also state-oriented. In these architectures, a session is a temporary logical connection over which two communicating entities send messages. Certain attributes are associated with the session, such as identifying information for each of the entities. These types of information are state-related information.
This session approach has been added to HTTP transactions by associating a Session Identifier ("Session ID") with each client. A session ID may be any type of identifier that serves to uniquely identify a particular client to the server. This session ID is then sent as part of the HTTP request syntax for each message sent from the client machine. The server uses the session ID to store information related to the transactions with this client, so that the series of transactions can be treated as a logical on-going communication between the client and the server (instead of simply as random, unrelated messages). This is how the server is able to accumulate the information required for a user to perform on-line shopping, and is also how servers can gather information about users that becomes part of a user's profile. The session then encompasses all requests from this client that use this same identifier.
Session IDs have been implemented on top of HTTP using two primary approaches. The first is through use of "cookies". The second is through "URL rewriting". A cookie is an abstract concept referring to storing state information, and passing a reference to that information between the client and server by including an identifier in the HTTP request and responses. When a client issues a first request to a server, the server will create a cookie for this client, and assign a session ID to the cookie. The cookie for the session is then passed back to the client with the response. On the client's subsequent requests, the client sends the session cookie as part of the request. A server typically provides services to many clients, and receiving the client's session identifier as a cookie enables the server to find the information it has kept about previous transactions with this particular client. Transferring the state information in this way allows the client and server to maintain state-related information. However, some browsers do not support cookies as part of the HTTP syntax, or they may allow users to disable cookie support, so the URL rewriting mechanism can be used instead. URL rewriting is a way of ensuring that requests sent to the server will have the session ID plugged into the URL. Web pages that are sent to the client machine often have hypertext links embedded in them. A hypertext link is an address the user can click on from the page, which may cause a request for a different page to be sent to the server. By putting the session ID into the address in that link, the server can maintain state information for the session. Processing by the server is required for rewriting the URLs. That is, before the server sends a page to a client, the server will check to see if the page has URLs embedded in it. If so, the server adds a session ID parameter and the unique identifier for this session into the URL syntax before sending the page.
The Java language is gaining wide acceptance for writing Web applications, as it is a robust portable object-oriented language defined specifically for the Web environment. ("Java" is a trademark of Sun Microsystems, Inc.) Web servers that implement a Java Virtual Machine can be functionally extended using Java "servlets". A servlet is a relatively small executable code object that can be dynamically plugged in, or added, to the code running on the server. Servlets typically perform some specialized function, which can be invoked by the server (or by another servlet) to extend its own functionality. The servlet processes the request, and returns the response to the server (or servlet) that invoked it. Any number of servlets can be running within one server at any given time.
The Java Web Server Toolkit from Sun Microsystems now provides a mechanism called Session Tracking, whereby state information can be maintained and made available to servlets. The state information is stored on the server using a session object. This object is created when a new client session begins, and is kept for the duration of the session. The object stores information about the transactions occurring between the client and the server. An interface to the object is defined so that servlets can access and modify the state information to reflect the transactions they process for that client. The session ID concept is used to correlate a particular session object to the proper client. This session tracking mechanism supports both cookies and URL rewriting for passing the session ID between the client and server (and subsequently to servlets). The session object has some predefined fields for which it will store values. Additional data can be stored with a developer-defined identifier, which can then be used to access the stored data later on.
A number of difficulties exist with session tracking as it is provided, however. The documentation for the Java Web Server Toolkit warns that developers should adopt a naming convention in order to avoid overwriting servlet data values, since an object is shared among servlets. Refer to "Java Web Server 1.1--Session Tracking", located at URL "http://jserv.javasoft.com/products/java-server/documentation/webserver1.1 /session.sub.-- track/SessionTr.html". Further, a limit is placed on the number of sessions that can exist in memory at any one time. This limit is discussed in the same documentation. A limit is used because a very large number of sessions can be active on a particular server, and the session object for each session can grow to an unpredictable size due to the fact that servlets can add any type of information to the object that they need for their function. The limit is implemented with a system variable (referred to as a "property") that specifies the maximum number of memory-resident sessions, and a swapping mechanism that swaps the least-recently used session objects to a disk file when the maximum number is exceeded. The session objects will then be swapped back into memory as they are needed. The swapping carries the performance penalty associated with writing to disk files, and also requires the developer to structure data objects added to the session object so that they are serializable. "Serializable" refers to defining a linear structure for a non-linear object, by which the non-linear object can be written to a linear data stream such as a disk file. Any structures of the session object that are not defined as serializable will not be written to disk when the rest of the object is swapped out. They remain in memory, thus restricting the amount of memory made available for new sessions by the swapping operation.
A common practice for scaling and increasing the capacity of Web servers and Web sites is to increase the number of computer hosts (servers) which perform HTTP processing. These groups of Web servers are shielded by a load-balancing host (such as IBM's Interactive Network Dispatcher) which directs HTTP requests to different Web servers in its pool of servers to spread out the demand. A pool, or group, of servers is also referred to as a cluster of servers. When session services are provided at these clustered servers, the group of sessions can logically be thought of as a pool, or cluster, of sessions. Since the Session Tracking facility in the Java Web Server Toolkit is only valid within the scope of a single Web server, the pool of sessions cannot be properly maintained among a group of clustered Web servers such as this. For example, if a client request is received at one server, and that server maintains information about the on-going session, there is no way for this version of the session information to be made available to a different server in the cluster if the next request from this client goes to a different server.
Accordingly, a need exists for a technique by which these shortcomings in the ability to provide session services in a clustered environment can be overcome. A technique is needed to ensure that servlets do not inadvertently overwrite each other's data that is being created for session state information, while still allowing those servlets to share each other's data. The database access performance penalty must be removed to enable servlets to function optimally. Further, to ensure wide acceptance of a solution, the technique must be portable and must use non-proprietary interfaces. The proposed technique uses a plug-in servlet engine to maintain session information among multiple computers for servlets in a clustered environment, and to provide session services to the servlets. Session information is maintained without using a persistent data store according to the preferred embodiment of this technique. Further, the proposed technique provides a locking mechanism for each session object, to ensure the integrity of the state information contained in the session objects. These benefits are provided using widely-available, non-proprietary features of an Application Programming Interface ("API") such as the Java API and Java Servlet API, allowing for scalability, portability, and maximum industry acceptance of this solution.